POV-Ray : Newsgroups : povray.general : POV-Ray in Challenge #21: The Bedroom : Re: POV-Ray in Challenge #21: The Bedroom Server Time
30 Jul 2024 02:15:22 EDT (-0400)
  Re: POV-Ray in Challenge #21: The Bedroom  
From: Reactor
Date: 10 Dec 2009 18:30:00
Message: <web.4b2184198fd451f8822e880c0@news.povray.org>
Christian Froeschlin <chr### [at] chrfrde> wrote:
>
> yeah, unless you count 'polySurface10933' as a label ...
> but I reckon their not labelled in the obj version either?
>

They are not, but Wings has a full GUI so it is easy to relabel them before
export.

> forgot to mention that the script replaces the texture definitions
> for easier replacement ;) Of course texturing is supposed to be part
> of the challenge so I assume that is why it's all lambert1
>
> Here's a sample how my pov file now looks like:
>
> // Triangles for object 'Bedframe' (12140 triangles)
> union {    // Surface 'lambert1'
> #include "inc/Bedframe.inc"
> texture {T_Bedframe}}
>

That's nifty!  Probably faster than doing it in Wings, but I am also adding uv
mapping info...

>
> I thought POV-Ray also uses a left-handed system too? A small test
> render seemed to show geometry oriented like in the forum thread.

POV uses the right hand system, and you are correct that rendering the scene as
downloaded does show the same orientation, but this is a consequence of the
right vector being declared as along the negative x axis (which I kind of
consider to be backwards :D ).  Anyway, this isn't too big of a deal.  I can't
remember whether or not that flips textures also, but those are easily
re-flipped by scaling a negative amount.

I am hoping that the geometry files will be much smaller after re-export, since
mesh2 is usually more compact, so that should help with the parsing time.  I am
curious as to how MCPov would do on this, but I have trouble running it under
XP64

-Reactor


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.